🔒 Security: fix command injection via project_name (Windows shell=True) - #29
🔒 Security: fix command injection via project_name (Windows shell=True)#29shunfeng8421 wants to merge 1 commit into
Conversation
_build_windows_command() builds a shell command string that is executed via create_subprocess_shell(shell=True). Three user- controlled values were interpolated without quoting: - self.project_name (from MCP tool argument) - command (from MCP tool argument) - args (from MCP tool argument) On Windows an attacker-controlled project_name such as 'test && calc.exe' results in arbitrary command execution. Fix: wrap all three interpolations with shlex.quote(). The Linux path (_build_unix_command) passes arguments as a list and was not affected.
|
Friendly ping on this security fix (command injection via project_name on Windows). It's been open for 7 weeks. The vulnerability allows RCE through the MCP deploy_compose tool. The fix adds shlex.quote() to all shell arguments. |
|
Bumping this security fix, open for ~7 weeks. Windows-only command-injection fix via |
|
Friendly follow-up on this security fix. The PR remains open and addresses Windows command injection through project_name interpolation before create_subprocess_shell(). Please let me know if the project prefers a different quoting or subprocess strategy. A review when convenient would be appreciated. |
1 participant
Summary
Fix command injection vulnerability in
WindowsExecutor._build_windows_command().Vulnerability
project_nameoriginates from the MCPdeploy_composetool argument and is interpolated directly into a shell command string without quoting:On Windows, this command is executed via
create_subprocess_shell(cmd, shell=True). An attacker-controlledproject_namesuch astest && calc.exeresults in arbitrary command execution.Affected
_build_unix_command) passes arguments as a list and is not affectedFix
shlex.quote()properly escapes shell metacharacters on both Windows and POSIX.Entry point